System for validating client data with third party systems

ABSTRACT

A computer system for validating user data based on third party data includes a system configured to obtain data, from third party computer systems, such as academic institution computer systems and job agency computer systems, indicative of graduation, subsequent unemployment and reasonable job search by an insured, relating to claim payments to cover interest or interest and principal repayment on tuition debt for a period of time after a student graduates, subject to the student engaging in a reasonable job search, with insurability and pricing based on underwriting factors such as type of school attended, grade point average and area of study.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 14/464,216, filed Aug. 20, 2014, entitled “System for Accessingand Validating Client Data with Third Party Systems,” which applicationis incorporated by reference herein in its entirety for all purposes.

BACKGROUND

The cost of tuition for higher education has skyrocketed in recentyears. Previously students could attend private and public collegeswithout building debt. However, with the rapidly rising price ofeducation today, it has become almost a certainty that college graduateswill be left with significant tuition debt upon receiving their degree.With the current yearly cost of a 4-year institution ringing in at about$34,000 for private schools and $17,000 for public institutions, notincluding living expenses and housing, it is becoming increasinglydifficult to pay for higher education without financing. Currently,about two-thirds of bachelor degree recipients had to take out loans toattend school, either through the government or privately.

The problem lies not in the loans themselves, but in the difficulty inpaying them off after graduating in our current job market. It has beenestimated that there are about 37 million student loan borrowers in theUnited States. Together, their loans add up to over $1 trillion dollarsand have exceeded mortgage based debt in this country. That being said,the lack of jobs for recent graduates, coupled with the massive tuitiondebt, is a similar set up to what recently occurred with the housingmarket. In many instances, college graduates have massive debt and theirincome is not enough to match the payments. This is potentially settingup the country to see a massive tuition loan default in the near future.

Currently, 48% of 25-34 year olds say that they are underemployed orunemployed. Considering that a significant portion of those 37 millionstudent borrowers would fall within that specific group, a real problemis surfacing. As it stands now, about 41% of borrowers become delinquentwithin the first five years, and that percentage is poised to go up. Asthe majority of high school graduates go to college and tuition risescreate an even greater need to take out loans, widespread defaults mayoccur. What is needed today is a way to insure against those loandefaults; to help graduates who do not find a job immediately aftergraduation (or one that matches their potential) from defaulting ontheir loans when their loan payments are due, considering grace periodsbuilt in to some loans.

Accordingly, there is a need for a system and process that addresses theneeds of graduates and the loan issues they face.

SUMMARY

The present invention in some embodiments to a computer system foradministering tuition debt insurance, the system comprising: at leastone processor; a memory coupled to the at least one processor; and oneor more programs, wherein the one or more programs are stored in thememory and configured to be executed by the at least one processor, theone or more programs including instructions for: receiving a tuitiondebt policy request from an individual via a mobile computing device,the request including request data comprising at least a school attendedby the individual and a performance characteristic associated with theindividual at the school; and generating pricing information based atleast in part on the request data; and displaying the pricinginformation and one or more tuition debt insurance coverage optionscorresponding to the pricing information to the individual; receiving aselection of a selected one of the tuition debt insurance coverageoptions; storing, in a policy record data storage device, a policyrecord associated with the selected tuition debt insurance coverageoption; and transmitting to the mobile computing device an indication ofcoverage for the individual for the tuition debt coverage option.

In some embodiments, the present invention relates to a computerimplemented method of operating a computer system to process aninsurance claim for tuition debt coverage, the computer implementedmethod comprising: receiving information identifying a claim and atuition debt coverage policy from a policyholder; retrieving, from apolicy database, information associated with the tuition debt coveragepolicy; requesting policyholder information related to at least agraduation date and job search data; validating the policyholderinformation related to the graduation date and job search data from atleast one third party database; determining a claim payment amount basedon the validated policyholder information; and issuing claim paymentinstructions for the determined claim payment amount.

In some embodiments, the present invention relates to a computer systemfor processing data for tuition debt insurance coverages, comprising: aninsurance data computer system comprising: one or more computerprocessors, and a computer usable medium, accessible by the one or morecomputer processors, having a computer readable program code embodiedtherein, said computer readable program code adapted to be executed toimplement a method for processing data for tuition debt insurancecoverages, said method comprising: receiving a tuition debt insurancequote request from a user; determining a price for the tuition debtinsurance quote request based at least in part on a school attended bythe user, a grade point average of the user, a loan identifier and agraduation date for the user; issuing an electronic communication to theuser, wherein the electronic communication includes at least one of apremium amount for the tuition debt insurance coverage; a communicationsdevice in communication with the insurance data system and incommunication with one or more networks for communicating the electroniccommunication to the user; and an insurance workflow computer incommunication with the insurance data system, the insurance workflowcomputer configured to receive data indicative of the electroniccommunication, and to determine one or more insurance-related workflowmodifications in response to receipt of the data indicative of theelectronic communication.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1 shows an exemplary computer architecture that may be used foradministering tuition debt insurance data;

FIG. 2 shows an exemplary system that may be used for the management andanalysis of tuition debt insurance data for insurance purposes;

FIG. 3 shows another exemplary system of the present invention;

FIG. 4 shows an exemplary process flow of the present invention;

FIG. 5 shows an exemplary data structure of an embodiment of the presentinvention;

FIG. 6 shows an graphical user interface of an embodiment of the presentinvention;

FIG. 7 shows another exemplary system of the present invention;

FIG. 8 shows a flow diagram of an audit process in an embodiment of thepresent invention; and

FIG. 9 shows a data table illustrating variables and factors used indetermining premiums in an embodiment of the present invention.

DETAILED DESCRIPTION

Disclosed herein are processor-executable methods, computing systems,and related technologies for achieving efficiencies in connection withtuition debt related data processing, and particularly processing andanalyzing of tuition debt insurance. Administration of tuition debtrepayment involves complicated and data intensive computer processing,including maintaining and updating records concerning millions ofdebtors whose records must be updated frequently due to such factors asfrequent changes in address and high rates of late payment, partialpayment, defaults and other difficulties in connection with loanservicing. Computer-implemented solutions that simplify data processingassociated with tuition debt repayment computer systems are desired. Thepresent system addresses complexities of data processing associated withtuition debt repayment computer systems by efficiently providing forinsurance data computer systems that arrange for payment directly tolenders and loan servicing agencies in connection with validated tuitiondebt insurance coverage claims. Moreover, embodiments of the presentsystem efficiently determine coverage start dates and validating claimsvia communications with third party data system such as data systems ofschools and other educational institutions, job search agencies, andother third party data systems. Furthermore, embodiments of the presentsystem efficiently use computer resources by underwriting and pricingtuition debt coverage accurately by using appropriate data elements suchas school type, academic achievement markers such as grade point averageand class ranking, and other suitable data for underwriting purposes,thereby avoiding inefficient burdens of high claim processing rates.

The present invention provides significant technical improvements toinsurance underwriting and insurance claims data processing technology.The present invention is directed to more than merely a computerimplementation of a routine or conventional activity previously known inthe industry as it significantly advances the technical efficiency,access and/or accuracy of insurance underwriting and insurance claimsdata processing by implementing a specific new method and system asdefined herein. The present invention includes systems and methods toimplement interactions of types not previously known in the art betweenspecialized computer systems. The present invention is a specificadvancement in the area of insurance underwriting data processing andinsurance claims data processing by providing technical benefits in dataaccuracy, data availability and data integrity, as well as benefits inefficiency of use of data processing, storage and processing resources,and such advances are not merely a longstanding commercial practice. Thepresent invention provides improvement beyond a mere generic computerimplementation as it involves the processing and conversion ofsignificant amounts of data in a new beneficial manner as well as theinteraction of a variety of specialized insurance, client and/or vendorsystems, networks and subsystems. For example, in the present inventionefficiencies are achieved in the processing of data relating toadministration of repayment of tuition debt, including avoiding the needfor numerous electronic communications related to late payments,delinquencies and collection of delinquent accounts.

Embodiments of the present invention addresses the needs of newgraduates with large student loan debt in conjunction with a difficultjob market by providing new graduates with student loan debt coveragefor a period of time after graduation if the graduate is not able tosecure employment for that period of time. Embodiments of the presentinvention implement computer processing arrangements for efficientlyprocessing data to achieve protection for insureds with protectionagainst risk of unemployment after the completion of an insurable degreefrom certain schools; computer processing arrangements of embodiments ofthe present invention provide for, in response to an approvable claim byan insured, providing the insured with payments to cover the interestand principal of federal and/or private student loans for a period oftime during such documented unemployment. The tuition debt coverage maybe a stand alone policy or coverage or added as an endorsement to acurrent auto, home, and/or rental policies or provided in conjunctionwith a 529 plan or other similar offering.

Features of some embodiments will now be described by first referring toFIG. 1 which illustrates a system architecture 100 within which someembodiments may be implemented. More particularly, FIG. 1 depicts asystem architecture 100 in which tuition debt protection plans andinsurance policies and insuring arrangements may be quoted, priced,issued and managed. Although the devices of architecture 100 aredepicted as communicating via dedicated connections, it should beunderstood that all illustrated devices may communicate to one or moreother illustrated devices through any number of other public and/orprivate networks, including but not limited to the Internet. Two or moreof the illustrated devices may be located remote from one another andmay communicate with one another via any known manner of network(s)and/or a dedicated connection. Moreover, each device may comprise anynumber of hardware and/or software elements suitable to provide thefunctions described herein as well as any other functions. Othertopologies may be used in conjunction with other embodiments.

According to the example architecture shown in FIG. 1, one or morerequestor or user devices/devices 110 are provided which comprisedevices that may be operated by a user such as an insurance agent, anindividual, a consumer, etc. seeking tuition debt coverage. The useroperating device 110 is associated with a certain school entity 114 andcertain tuition debt 118. Requestor device 110 may interact with Webpages provided by Web server 134 to request a quote, a recommendationand/or to provide data relating to the kinds and options of tuition debtcoverage. Web server 134 may include a web application module and aHyperText Transfer Protocol (HTTP) server module. The web applicationmodule may generate the web pages that make up the web site and that arecommunicated by the HTTP server module. Web application module may beimplemented in and/or based on a technology such as Active Server Pages(ASP), PHP: Hypertext Preprocessor (PHP), Python/Zope, Ruby, anyserver-side scripting language, and/or any other appropriate technology.

The HTTP server module may implement the HTTP protocol, and maycommunicate HyperText Markup Language (HTML) pages and related data fromthe web site to/from client devices using HTTP. The HTTP server modulemay be, for example, a Sun-ONE Web Server, an Apache HTTP server, aMicrosoft Internet Information Services (IIS) server, and/or may bebased on any other appropriate HTTP server technology. The web sitesystem may also include one or more additional components or module,such as one or more switches, load balancers, firewall devices, routers,and devices that handle power backup and data redundancy.

This data may be transmitted to the insurance systems 130 to determine arecommendation as described in detail below. More particularly, pursuantto some embodiments, the requests and applications may be additionallyassociated with requests for personal line or so called property andcasualty based insurance policies (such as, for example, automobilepolicies and homeowner policies). The requests described herein may bereceived from individuals or entities seeking insurance coverage or forrequests for insurance information. For example, with respect toapplications for tuition debt insurance, information such as the cost ofthe insurance, the term of the insurance, the payment options, the claimprocedure and the payout options may be requested. Information may berequested from the user related to the request for tuition debt coverageand may include, but not be limited to type of school (non-limitingexamples of school type including Ivy, Non-Ivy bachelor's degreegranting institution, Technical, Vocational), the user's major, minor orother field of study, GPA, age, gender, amount of time in school, jobhistory, leadership history and related co-signer information.Insurability conditions may include that the school is an accreditedschool, accredited by at least one accrediting entity.

As used herein, insurance coverage options may comprise a set of one ormore insurance coverages or policy features. Each of the one or moreinsurance coverages or features may insure against one or more riskssuch as unemployment with tuition debt, and provide one or more benefitssuch as payment of interest and principal of tuition debt. In thepresent description, an insurance coverage defines the parameters of therisk(s) which are covered thereby, and a configuration is a set of oneor more insurance coverages, including specified payments, paymentplans, limits and deductibles for each of the one or more insurancecoverages.

Any number of requestor devices 110 may be employed to receive customerand insurance request data and to present insurance coverage and otherinformation to users or operators of the requestor devices 110.Requestor devices 110 may include but are not limited to cellulartelephones, handheld wireless communication devices, personal digitalassistants, pagers, laptop computers, tablet computers, smartphones,other mobile display devices, glasses based computing devices, orcombinations thereof.

The requestor devices 110 may be in communication with an insurancecompany 130 or other provider via a Web server 134 or other front endinterface that allows remote terminals to send and receive data to theinsurance company. The customer and insurance request data are receivedvia the Web server 134 and are stored by data warehouse 140 for lateraction such as an insurance workflow action or process. Any number ortype of data storage systems may store the data in any suitable manneraccording to some embodiments. Non-exhaustive examples include arelational database system, a spreadsheet, and any other data structurethat is amenable to parsing and manipulating data. Data warehouse 140may be managed by one or more database management systems which may bebased on a technology such as Microsoft SQL Server, MySQL, OracleRelational Database Management System (RDBMS), PostgreSQL, a NoSQLdatabase technology, and/or any other appropriate technology. Datawarehouse 140 may receive and store customer and application data aswell as store insurance coverage package data and rules which are usedin the quoting component 126 and the configuration component 122.

The configuration component 122 acts to receive the customer orinsurance request data, such as tuition debt policy requests, and toretrieve tuition debt insurance coverage package data and rules from thedata warehouse 140. Configuration component 122 may identify one or moreinsurance coverage options, configurations and/or packages based on thereceived data and on data received from Web server 134. Pursuant to someembodiments, different tuition debt insurance packages or differentcoverage options are assembled for presentation to the customer based onconfiguration rules and information associated with each request. Forexample, one tuition debt insurance package may include a coverageoption for payment of interest and principal on a federal or privatestudent loan for 12 months after graduation, or 12 months after thefirst payment is due, provided the insured has made reasonable effortsto secure full time employment and has met all other policy conditions.

When an appropriate tuition debt coverage option is identified by theconfiguration component 122, pricing data for the tuition debt insurancecoverage option may be generated by the quoting component 126 and thenpresented to the customer or agent via a Web page or other userinterface for viewing by a requesting individual on a display screen ofa requestor terminal 110. The display screen may be configured, such asvia soft keys, radio buttons or other user interface elements, to prompta user to select a displayed tuition debt insurance coverage option. Thedisplay screen may be configured to cause the selection of a selectedone of the tuition debt insurance coverage options to be transmitted toinsurance systems 130. Insurance systems 130 may route the selection topayment/policy component 128. Payment/policy component 128 may generateinsurance policy documents corresponding to the selected one of thetuition debt insurance coverage options, cause policy record data to begenerated and stored in a policy record data storage device 140, andgenerate billing data and billing statements associated with theselected coverage option. Payment/policy component 128 may also generatean indication of coverage, such as a policy document, an endorsement orother suitable confirmation of coverage. The indication of coverage maybe transmitted to the requestor terminal 110 for display as anelectronic communication, including a premium amount for the tuitiondebt insurance coverage. Referring again to the system of FIG. 1, eachof the components 122, 124, 126, 128 and the insurance systems 130 maycomprise any combination of hardware, software and/orprocessor-executable instructions stored on a non-transitory, tangiblemedium. According to some embodiments, one or more of the components122, 124, 126 or 128 may be a component of the data warehouse 140 or theinsurance systems 130.

In some embodiments, insurance systems 130 may include an insuranceworkflow computer. In embodiments, an insurance workflow computer systemmay be configured to receive data indicative of the electroniccommunication issued to the requestor terminal, and to determine one ormore insurance-related workflow modifications in response to receipt ofthe data indicative of the electronic communication. Insurance-relatedworkflow modifications may include storing a graduation date of aninsured as a policy activation date, determining a premium schedulebased on the policy activation date, setting flags to contact theinsured regarding meeting policy requirements, such as graduation, gradepoint average, continuation as a student in good standing, and otherrequirements, and other workflow modifications.

It should be noted that embodiments are not limited to the devicesillustrated in FIG. 1. Each device may include any number of disparatehardware and/or software elements, some of which may be located remotelyfrom one another. Functions attributed to one device may be performed byone or more other devices in some embodiments. The devices of system 100may communicate with one another (and with other non-illustratedelements) over any suitable communication media and protocols that areor become known.

FIG. 2 is a block diagram of a computer system 200 according to someembodiments. Computer system 200 may perform the functions attributedabove to the configuration component 122 of FIG. 1. Computer system 200includes computer processor 201 operatively coupled to communicationdevice 202, data storage device 204, one or more input devices 206 andone or more output devices 208. Communication device 202 may facilitatecommunication with external devices. Input device(s) 206 may comprise,for example, a keyboard, a keypad, a mouse or other pointing device, amicrophone, knob or a switch, an infra-red (IR) port, a docking station,and/or a touch screen. Input device(s) 206 may be used, for example, toenter information into computer system 200. Output device(s) 208 maycomprise, for example, a display (e.g., a display screen) a speaker,and/or a printer.

Data storage device 204 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g.,magnetic tape and hard disk drives), optical storage devices, and/orsemiconductor memory devices such as Random Access Memory (RAM) devicesand Read Only Memory (ROM) devices. Data storage device 204 storesprogram instructions for execution by processor 201. Configurationcomponent 210 may comprise a set of such instructions, and may beexecuted by processor 201 to cause system 200 to operate as describedabove with respect to configuration component 122 of FIG. 1. Thisoperation may initially include operation of communication device 202 toretrieve tuition debt policy rules and criteria including, for example,no tuition debt product option rules 211, claim rules 212, unemploymentvalidation rules 213, school qualification rules 214, loan validationrules 215 and deductible rules 216. In some embodiments, and asdescribed with respect to FIG. 1, data storage device 204 may comprise adata warehouse or network or cloud type storage facility or mechanismthat is in communication with one or more third party databases orservers 220 and 230.

One or more public cloud, private cloud, hybrid cloud and cloud-likenetworks may also be implemented, for example, to store, handle andconduct processing of one or more transactions or processing ofembodiments of the present invention. Cloud based computing may be usedherein to handle any one or more of the application, storage andconnectivity requirements of embodiments of the present invention. Forexample one or more private clouds may be implemented to handle tuitiondebt policy and claims data of embodiments of the present invention.Furthermore, any suitable data and communication protocols may beemployed to accomplish the teachings of embodiments of the presentinvention.

Data storage device 204 may store other data used and/or generatedduring operation according to some embodiments. For example, the datastorage device 204 may store data including configuration rules, policyrules, or the like. The nature and usage of this stored data accordingto some embodiments will be described in detail below. Each of the rulesstored in the system 200 may include data defining a tuition debt policyor claims feature or option. For example, the following individualtuition debt policy features may be provided, some of which may becombined into one or more packages of features such as a packageincluding home and tuition debt insurance, a 529 plan and tuition debtinsurance, auto and tuition debt insurance, and renter's and tuitiondebt insurance, as non-limiting examples.

In some embodiments, rules associated with various product features maybe specified as product rules 211. Product rules 211 may specify themode, type and frequency of premium payments such as rules related toelectronic fund transfer of premium payments to the insurer from theinsured. Product rules 211 rules may prescribe how a third party such asa parent or other individual or institution may make whole or partialpayments on behalf of a student insured. Product rules may provide thatthe coverage period expires upon the individual securing a first job.The product rules may provide parameters for a job to qualify as endingthe coverage period, such as completion of a trial or probationaryperiod, minimum salary, minimum weekly or other periodic hours, andother requirements.

In some embodiments, rules associated with claims may be specified asclaim rules 212. Claim rules 212 may specify the manner, timing andduration of claim payments that may be made under the tuition debtcoverage. An exemplary claim rule 212 may prescribe how claim paymentsmade be made for a period of 6-18 months during the time the insured isunemployed. The claim payment period may end upon the insured securing ajob.

In some embodiments, rules associated with unemployment validation maybe specified as unemployment validation rules 213. Unemploymentvalidation rules 213 may relate to standards used in determining whetherthe insured has met certain standards such as applying for a certainamount or type of jobs and whether the insured has filed forunemployment with a state as an example. Unemployment validation rules213 may interface with one or more third party systems 220 such as asystem associated with an employment agency or headhunter, a schoolplacement office and/or a state unemployment office.

In some embodiments, rules associated with school qualification rulesmay be specified as school qualification rules 214. School qualificationrules 214 may relate to certain standards and requirements for potentialinsureds to qualify for the tuition debt insurance or qualify forcertain premium rates or discounts. For example, school qualificationrules 214 may include guidelines on schools such as certain tier ratingsand other evaluation criteria for certain school, majors within theschools and GPA within the schools.

In some embodiments, rules associated with loan validation may bespecified as loan validation rules 215. Loan validation rules 215 mayinclude guidelines and requirements for verifying and validating insuredloans such as loan balance, loan payment information and loan type as anexample. Load validation rules 215 may interface with one or more thirdparty systems 230 such as a system associated with the U.S. Departmentof Education that may be administering one or more federal student loanprograms. Federal loan programs may include The William D. Ford FederalDirect Loan Program that may administer loans such as Direct SubsidizedLoans, Direct Unsubsidized Loans, Direct PLUS Loans, and/or DirectConsolidation Loans. Another qualifying loan program may include TheFederal Perkins Loan Program and other similar federal and/or privatestudent loan programs that may be administered by Sallie Mae, CharterOne TruFit, Citizens Bank TruFit, Connecticut Higher EducationSupplemental Loan Authority (CHESLA), Think Financial and others.

In some embodiments, rules associated with deductibles may be specifiedas deductible rules 216. By way of non-limiting example, policy holderswho have either or both auto and home insurance policies may enjoycombined, disappearing or reduced deductibles based on the combinedpolicies with the tuition debt policies. For example, in someembodiments, a combined policy may include deductible reduction featureswhere the policy holder may receive a deductible reduction on his or herauto policy based on activity on the home policy (or vice versa). Insome embodiments, payment of a deductible amount on one of the policies(e.g., such as the homeowners policy) may result in a waiver of all or aportion of the deductible (in a given policy year, for example) on theother policy (e.g., such as the tuition debt policy).

Referring still to FIG. 2, by applying one or more rules andconfiguration criteria, the configuration component may respond torequests for insurance with tuition debt policy options having certainpricing, underwriting requirements and feature sets. An option may beselected or accepted by a customer, and a corresponding tuition debtinsurance coverage policy issued by the insurance company, naming theselected individual as insured. Once a policy has been issued,embodiments provide systems and methods for claim processing. Moreparticularly, embodiments allow claims to be processed once a certainthreshold has been reached for graduation and employment effortguidelines. The processing of such claims will now be described by firstreferring to FIG. 3 which illustrates a claim processing architecture300 within which some embodiments may be implemented.

In particular, in the claim processing architecture 300 of FIG. 3, aninsured who has recently graduated and who has suffered a loss involvingproperty covered by each of those policies, is able to submit a claimduring a predetermined term of his unemployment using the architecture300. Although some devices of architecture 300 are depicted ascommunicating via dedicated connections, it should be understood thatall illustrated devices may communicate to one or more other illustrateddevices through any number of other public and/or private networks,including but not limited to the Internet. Two or more of theillustrated devices may be located remote from one another and maycommunicate with one another via any known manner of network(s) and/or adedicated connection. Moreover, each device may comprise any number ofhardware and/or software elements suitable to provide the functionsdescribed herein as well as any other functions. Other topologies may beused in conjunction with other embodiments.

According to the example of FIG. 3, policy servers 310-314 store policyinformation associated with one or more insurance policies such as home,auto, commercial and tuition debt related policies. Policy informationmay include any combination of policy-related data fields that are orbecome known, including but not limited to policy type, policy number,insured name, deductibles, coverage limits, riders, endorsements andexceptions. Each of policy servers 310 through 314 may comprise anycombination of hardware and/or software, including but not limited torelational databases, application servers, and spreadsheets. One or moreof policy servers 310 through 314 may comprise a policy issuing system,a data warehouse of an insurance company or any other aggregator ofinsurance policy information.

Pursuant to some embodiments, policy server 310 is a source of personallines automobile policies which have been issued by an insurer, policyserver 312 is a source of homeowner policies and policy server 314 is asource of tuition debt policies or endorsements. The homeowner,automobile and tuition dent policies may be maintained by separatebusiness groups of an insurer and thus be maintained on different policyservers and systems (such as server 310-314) or they may be maintainedon integrated servers, platforms or database systems.

Each of policy servers 310 through 314 may provide policy information tosystem 320 asynchronously or according to any schedule. In someembodiments, one or more of policy servers 310 through 314 provides adaily feed of policy information to system 320. The policy informationof the feed may be associated with new insurance policies for which aninitial premium has been paid or renewal policies for which additionalpremium are due.

System 320 may comprise any combination of hardware and software toperform processes as described herein. According to some embodiments,when an insured party submits a claim or request for information about apolicy, system 320 receives policy information associated with aninsurance policy from one of sources 310 through 314 and processes theclaim or other request. In general, however, when a request is receivedinvolving a policy stored in one of the policy servers 310 through 314,the data is retrieved and returned to system 320 for processing.

System 320, as well as claims management system 330 may comprise programinstructions of a database management system, database procedures and/ordatabase applications to process the data stored at those systems orretrieved by those systems. One or more administrator terminals ordevice 325 may be in communication with system 320 and configured toprovide display screens representing data stored in system 320 andoptions to permit an operator to edit this data and to otherwise providecommands to system 320. For example, an administrator terminal or device325 may be configured to permit an operator to input commands via a userinterface to update a data structure including information associatedwith a claim or the like. Terminal 325 may comprise any suitable deviceincluding one or more input devices, such as keyboards, touchscreens andpointing devices, and display devices such as display screens, includingbut not limited to a desktop computer, tablet computer, and/orsmartphone.

Claim management system 330 may receive policy records and associatedclaim handling identifiers from system 320. Claim management system 330may receive a report of a claim associated with an insurance policy anddetermine the claim handling identifier of the record associated withthe insurance policy. A customer service representative may use theclaim handling identifier to assign the claim to the appropriateclaim-handling organization. In this regard, customer servicerepresentatives may operate terminal 340 to access the records of claimmanagement system 330. All terminals described herein may comprise anysuitable devices for requesting and displaying user interfaces,including but not limited to desktop computers, cellular telephones,personal digital assistants, and laptops.

According to some examples, an insured individual who has a claim suchas experiencing unemployment after graduation submits a claim to aninsurance processing system 330 over a network interface. For example,the claim may be submitted using a smartphone 350 or a personal computer355 to transmit claim information to the claims management system 330.

Whether the claim is submitted via smartphone 350 or computer 355, theclaim request is routed to a device 342 associated with a customerservice representative. For example, the insured individual may operatesmartphone 350 to call a claim-reporting telephone number provided by aninsurance company. The call is passed through a network 360 (e.g., thePublic Switched Telephone Network, a cellular network, and/or anInternet Protocol network) and terminates at device 342 of a customerservice representative. Embodiments may also or alternatively provideclaim reporting via one or more other communication modes, such asfacsimile, electronic mail, text or World Wide Web.

The customer service representative receives an identifier of theinsured's policy (e.g., name, policy number, social security number,etc.) and operates a client application executed by terminal 340 toretrieve a record of claim management system 330 associated with thepolicy. The customer service representative determines a claim handlingidentifier of the record and assigns the claim based thereon. Dependingon the nature of the claim handling identifier, assignment of the claimmay include providing a telephone number of a third-party administratorto the insured or transferring the telephone call to a claim-handlingorganization of the insurance company. A process is then performed bythe claim management system 330 to determine if the claim is valid suchas by accessing rules relating to policy claim requirements, accessingclaimant data, and applying the rules to the claimant data. By way ofexample, the rules may relate to requirements to verify efforts by theclaimant to obtain employment, and the accessed data may include dataobtained from claimants, employment agencies and other third partiesincluding data indicative of applications and resumes submitted,interviews attended, and other information relating to employmentefforts by the claimant. Similarly, rules and accessed data may relateto validating the interest and premium payment amounts and processassociated with the claimant.

The insurance system 300 of FIG. 3 may provide other administration andmaintenance features associated with policies issued pursuant toembodiments of the present invention. For example, a system server 320may operate to receive and process policy change or update requests andmay generate an interface or display screens to allow faster and easierpolicy service. Agents and insureds may interact with the system 320 tomanage customers policy changes in real-time by performing actions suchas: (i) updating employment information, (ii) provide an immediate orsubstantially real time confirmation on a wide variety of policychanges, and (iii) view a billing breakdown, print ID cards and forms,etc.

Server 320 may also include a third party interface to controlcommunications between third party systems and claim data associatedwith claims processed using claim management system 330. For example, athird party interface may facilitate communication to secure third partydata related to an insured who has initiated a claim. As a specificillustrative example, for an insured who has initiated a claim for atuition debt policy third party interface may provide informationrelated to the claimant's student loan and/or employment effortinformation such as from a placement firm or headhunter type firm.

In some embodiments, server 320 may also include a notification moduleor code administering and applying notification and messaging rulesassociated with individual policies and policy features pursuant to thepresent invention. For example, the notification code may operate togenerate one or more notifications to insured customers or vendors. As aspecific example, all active policies stored in policy stores 310-314may be monitored to identify any upcoming “trigger” events or dates,such as the expiration or activation of a benefit such as activationupon graduation of the insured from the approved school or university.

A number of notifications may be generated using the notifications codeof server 320. These notifications may vary depending on the policyfeature included in a policy. For example, for insureds having tuitiondebt based coverage, automated notifications/reminders via email orotherwise of existence of the coverage itself may be generated such asupon a predetermined date of graduation from an institution previouslyprovided.

In some embodiments, policyholders may be provided with one or moreoptions to change features for other benefits, e.g. to increase theircoverage amounts or link to a related policy such as an auto or homepolicy. It should be noted that embodiments are not limited to thedevices illustrated in FIG. 3. Each device may include any number ofdisparate hardware and/or software elements, some of which may belocated remotely from one another. Functions attributed to one devicemay be performed by one or more other devices in some embodiments. Thedevices of system 300 may communicate with one another (and with othernon-illustrated elements) over any suitable communication media andprotocols that are or become known.

FIG. 4 is a flow diagram of a computer-implemented process 400 accordingto some embodiments. Various elements of system architecture 300 mayexecute process 400 according to some embodiments. Process 400 may beembodied within program instructions of claim management system 330, butembodiments are not limited thereto. Process 400 and all other processesmentioned herein may be embodied in processor-executable programinstructions read from one or more computer-readable media, such as afloppy disk, a CD-ROM, a DVD-ROM, a Zip™ disk, and a magnetic tape, andthen stored in a compressed, uncompiled and/or encrypted format. In someembodiments, hard-wired circuitry may be used in place of, or incombination with, program instructions for implementation of processesaccording to some embodiments. Embodiments are therefore not limited toany specific combination of hardware and software.

Process 400 may be performed in response to a claim notificationsubmitted by an insured individual (e.g., using the system of FIG. 3).More particularly, the process 400 is performed when a claimnotification is submitted for a tuition debt policy issued pursuant toembodiments of the present invention. The process, as will be described,allows an insured individual to enjoy the benefits of the tuition debtcoverage in the event the insured has made reasonable efforts to secureemployment but is currently unemployed with tuition debt. Further, theprocess allows an insurance company or other entity providing insurancecoverage to efficiently and accurately track such transactions so thatpolicy data may be updated to appropriately record the claims.

Processing begins at 410 where an insurance system (such as the system300 of FIG. 3, and more particularly, the claims processing system 330of FIG. 3) receives claim information and tuition debt policyinformation. For example, the claim and tuition debt policy informationmay include data submitted or otherwise provided by an insured (e.g.,via a phone 350 or computer 355) to an agent or other representative(e.g., operating a phone 342 or computer 340). The claim informationreceived may include information identifying the insured, the tuitiondebt coverage policy, and/or the loan to be paid, etc. The claiminformation may also include information about the insured's graduationdate and/or information related to their employment efforts. The policyinformation may include information such as a policy identifier oraccount number.

Processing continues at 420 where the insurance system retrievesinformation associated with the tuition debt coverage. For example, insome embodiments, each policy may have an identifier associated with itthat identifies a certain insured, a certain school associated with theinsured, a graduation date, a loan identifier, etc.

Processing continues at 430 where the insurance system requestspolicyholder information related to graduation and certain job searchdata. This request may be made, for example, by presenting a series ofquestions to the insured, by the insured responding to a series ofquestions in a survey or claim form, or the like.

Processing continue at 440 where the insurance system validates thepolicyholder information related to the graduation and job search data.The insurance system may request from a computer system of a schoolproof of graduation from the school by the individual. If processing at440 indicates that that the data is not valid, such as by accessing athird party database stating that the policyholder did not graduate, ora job search agency database indicating that the policyholder did notperform a reasonable job search as required in accordance with policyterms, the system will request additional information from thepolicyholder. If processing at 440 indicates that the policyholderinformation is valid, processing continues at 450 where the insurancesystem a claim amount to be paid is determined. This processing may beperformed, for example, by retrieving policy records from policy stores310-314. An example of related policy records are shown below inconjunction with FIG. 5.

Processing continue at 460 where the insurance system operates to issuecertain claim payment instructions based on the determined claim paymentamount. Instructions may be in the form of direct deposit or electronicfund transfer type instructions that specify a payment amount and apayment mode. For example, payment may be made direct to a loan providersuch as a Sallie Mae or the Federal Government. In embodiments, paymentmay be made to the insured or policyholder. The period and term of suchpayments may be specified such as a monthly period over a year term.

If after additional information is requested from the claimant, and theadditional information is not received, or is not sufficient to showmeeting claim requirements, the claim may be denied. A denialnotification may be provided via electronic communication. Denial mayresult from failing to meet thresholds such as posting of resumes on oneor more job search sites or social networking sites, failure to submitapplications to a minimum number of potential employers, and otherfactors. Such factors may be weighted and included in one or morealgorithms to determine whether a threshold level of job search efforthas been achieved. For example, a minimum number of total points in analgorithm including number of postings on job search sites, submissionsof resumes, submissions of applications, in person visits to potentialemployers, telephone calls to potential employers, validated networkingmeetings, telephone calls and e-mails with individuals having positionsproviding knowledge of possible job openings, numbers of connections onbusiness social media sites such as the LinkedIn® social networkingsystem, may be provided. The algorithms may provide for differentweightings dependent on industry or field pertinent to the degree of theindividual. Thus, an algorithm applied to an individual with acommunications degree may rank highly applications and contacts withbusinesses and individuals in the marketing and publishing industries,and weight lower contacts with engineering firms, while an algorithmapplicable to an individual with an engineering degree may rank highlycontacts with engineering firms and individuals in the engineering fieldand weight relatively low contacts with publishing and marketing firms.The algorithms may require sustained job search over a period of time,such as meeting a minimum number of points on a monthly basis for aperiod of months to qualify for claim payments.

Reference is now made to FIG. 5 which is a tabular representation of aportion of a tuition debt insurance database record 500. Tuition debtinsurance database record 500 includes a number of data fieldsrepresenting data associated with a particular insured. Only severalfields such as 510, 520 and 530 are identified for each policy recordfor convenience and ease of exposition—those skilled in the art willappreciate that a typical record may have more fields and data elements.Some or all of the data populating tuition debt insurance databaserecord 500 may be obtained or generated during an insurance policyunderwriting process, policy issuance process (such as by the system 100of FIG. 1), during a policy renewal process or claims process.Embodiments are not limited to the fields shown in FIG. 5, and each datafield need not be populated in some embodiments. Database record 500 mayalso be tagged, relational or linked such as to data records 540, 550 or560. Database record 500 may be used to underwrite a specific user orindividual such as may be described in record 540 to obtain for example,an average premium exposure 550 as well as an adjusted premiumcalculation 560.

An illustrative example of a system 600 including a user device 610accessing a user interface 614 for the purchase and administration oftuition debt insurance is shown at FIG. 6. User interface 614 may be apptype screen that provides access to an insurance company app as an appprovided by The Hartford. As shown, The Hartford app 618 is configuredto provide a user interface 620 that may display an application form 630for the initiation and completion of tuition debt insurance coverage.Application form 630 may request and the user may provide, as tuitiondebt policy request data, information such as Name, Company, Email,Phone, Social Security Number, Existing policy information, Type ofschool (Ivy, Non-Ivy, Technical, Vocational), Major, GPA, Age, Gender,Amount of time in school, Job history, Leadership history, Co-signername, Co-signer history, and other related information.

Tuition debt coverage options may include an option in which theinsured, or policyholder, is responsible for payment of a portion of thepremium payments. A sponsoring party, such as a parent or otherrelative, may agree to be responsible for another portion of the premiumpayment.

User interface 620 may also be configure to display two or more coverageoptions that have been identified (e.g., by the system 100) as beingavailable to a consumer seeking tuition debt insurance. In the userinterface shown, a script is dynamically generated for to generatepricing and explain the differences between the two packages. In thismanner, customers, agents and other representatives may easily selectand bind policy features that have desirable benefits to the customers.Those skilled in the art will appreciate that a wide variety and type ofuser interfaces may be provided, and that the system 600 is provided forillustrative purposes only. User interface 620 may also be configured toprovide access to an insurance claim system for reporting and managing aclaim under the tuition debt coverage.

Claim options may be provide that include options involving deductiblesunder the tuition debt coverage and/or claim payment processes. In oneembodiment, the Claimant pays ¼ of the monthly payment while anotherentity such as the insurer pays ¾ of the monthly payment where if theclaimant stops paying, the entity ceases payments as well. In anotherembodiment involving a delayed claim payment process, the tuition debtcoverage may require claimants to pay the first several payments whereanother entity would then pick up 12 months of coverage after deductibleperiod.

Referring to FIG. 7, another illustrative example of a tuition insurancedebt administration system 700 including a user device 710 for accessinga tuition debt insurance user interface 720 for the purchase andadministration of tuition debt insurance is shown. User device 710 mayobtain tuition debt insurance during an enrollment period 730 thatcorresponds to a period prior to graduation of an insured entity. Userdevice 710 may interact with an insurance processing system 740 toobtain the tuition debt insurance from a begin date up to an end date.In embodiments, the end date may be a period prior to a date ofgraduation 732. In embodiments, an end date may be from three months,six months, one year or two years prior to a date of graduation. Afterthe date of graduation 732, the insured may commence a job search duringa period 734 that corresponds to post the date of graduation 732 andprior to filing a claim 736. If the insured's effort to secure a job areunsuccessful, the insured may file a claim only after the date ofgraduation 732 and completing a good faith effort for a job searchduring period 734. The graduation date and job search efforts may bevalidated by information server 750 once the insured files for a claim,such as by submitting a claim using user device 760 to transmit claiminformation to the claims management system 770. Claim management system770 may administer the claim during a coverage period 738 that is afterthe graduation date 732 and job search period 734.

In embodiments, a system according to an embodiment may be configured toreceive and process a tuition debt policy request, for coverage of anindividual, prior to the covered individual being enrolled in a collegeor university. In an embodiment, the system may be configured to acceptand process a tuition debt policy request on condition that the coveredindividual be accepted at a college or university. The determination ofone or more policy parameters, including, by way of example, premiumamount, maximum term of benefit payments, and amount of benefitpayments, may be dependent only on the school. In embodiments, thedetermination of policy parameters may be dependent in addition to theschool, on one or more performance characteristics in high school, suchas grade point average and/or percentage class rank, in addition to theschool.

In embodiments, a system may be configured to receive a tuition debtpolicy request for coverage of an individual prior to acceptance at oneor more colleges or universities. In embodiments, the system may beconfigured for receiving and issuing policies for coverage ofindividuals of a threshold minimum age or educational attainment. By wayof example, the system may be configured for receiving a request from aperson other than the covered individual for issue of a policy. Thesystem may require that the request be from a person having one of anumber of specified relationships with the covered individual, such as aparent, step-parent, guardian or grandparent, by way of example. Thesystem may be configured to issue a policy to the person having therelationship with the covered individual, the policy identifying thecovered individual as the insured. The system may be configured to storedata indicative of the person to whom the policy is issued, as well asthe covered individual.

Referring to FIG. 8, in embodiments, on a periodic basis, an auditprocess may be conducted. By way of example, on a periodic basisfollowing policy issue, an audit may be conducted to determine whetherpresent data relating to the insured is consistent with stored datarelating to the insured. The system may be configured for generating 810a display for the user to respond to one or more questions to confirmsuch data as: current enrollment school, current enrollment status,e.g., full-time, part-time, number of credits of current enrollment, oron leave; current major, minor, area of concentration or the like;current grade point average and current class rank. In embodiments, thesystem may be configured to request confirmation of current statusdirectly from a school, or to receive images of documents verifyingcurrent status. The display may include check boxes and/or radiobuttons, text input fields, and interfaces to provide images ofdocuments, by way of example. In embodiments, the display may begenerated via a web server system for display via a browser client on auser device. In embodiments, the display may be generated by a serversystem interacting with application software being executed by aprocessor on a user device. The user device provides responsive data,such as via a web server system, to the system.

The system receives 815 data responsive to the inquiry to the user. Thesystem may then verify that the received data includes responses to allquestions, and documentary data where requested. If the verificationshows that the received data is not complete, then the system mayprovide supplemental inquiries to the user. Upon verification that thereceived data is complete, the system may then compare 820 the receiveddata with stored data relating to the policy. If all data is the same orwithin any applicable thresholds 825, such as an expected change inclass standing, or a change in GPA within a threshold, then the systemmay determine that there is no premium change, and provide 830 a messageto a policy holder and/or insured stating that there is no premiumchange. If one or more data items have changed beyond a threshold, suchas a change in school, a change in area of study outside a threshold, orother change, then the system may determine that a premium must berecalculated 835. In embodiments, a premium recalculation may use a sameequation or algorithm as an initial premium calculation, or a differentalgorithm. One or more limits may be used to limit a percentage ordollar amount of premium change. The system may then notify 835 thepolicyholder of the recalculated premium. Updated data relating to theinsured, such as current school, GPA, area of study and class standingmay be stored for use in a next audit.

Referring to FIG. 9, there is shown an exemplary data table 900 showingdata items stored in a database in embodiments of the invention and usedin determining premiums. In embodiments, a premium for a policy may bedetermined based on a base premium, multiplied by a weighted averagefactor. The weighted average factor may be a weighted average of factorsincluding one or more of factors indicative of a college tier 910, gradepoint average or other performance characteristic 920, area of study930, driving record 940, past job experience 950 and class standing 960,as shown, by way of non-limiting example. Other data, such as creditscore and other financial data may be employed in embodiments. A factormay be associated with each value of each of the variables. At 970, aweighted average factor for the student is shown. For the two studentsshown at 980, 990, exemplary different values are shown.

In embodiments, one or more benefits may be provided at a no cost ordiscounted basis to insureds. Such benefits may include access to careerservices, such as job search agencies or employment counselors,assistance with resume preparation, interview preparation and practice,as well as services such as financial planning services, real estaterelated services in connection with obtaining rental or purchasedhousing within commuting distance of a new job. In embodiments, acomputer system of the present invention may provide data in suitableformat, such as a suitably formatted xml message, to a computer systemof a provider of career services, financial planning services or realestate related services, including an identification of the insured, theidentification including contact information such as e-mail address,mobile phone number or other suitable contact information, and anindication that the insured qualifies for no cost or reduced costservices. In response, the recipient computer system may direct acommunication to the insured to invite the insured to access theavailable services.

In embodiments, a covered event may include unemployment, of any periodor more than a threshold period of time, prior to expiration of the termof the loan.

The embodiments described herein are solely for the purpose ofillustration. Those in the art will recognize that other embodiments maybe practiced with modifications and alterations limited only by theclaims. For example, though the methods and features described abovewith reference to FIGS. 1-9 are described above as performed using theexample architecture 100 of FIG. 1 and the exemplary system 200 of FIG.2, the methods and features described above may be performed using anyappropriate architecture and/or computing environment. Although featuresand elements are described above in particular combinations, eachfeature or element can be used alone or in any combination with orwithout the other features and elements. For example, each feature orelement as described with reference to FIGS. 1-9 may be used alonewithout the other features and elements or in various combinations withor without other features and elements. Sub-elements of the methods andfeatures described above with reference to FIGS. 1-6 may be performed inany arbitrary order (including concurrently), in any combination orsub-combination.

what is claimed is:
 1. A computer system comprising: (a) a coverageprocessing computer system including at least one coverage processorconfigured for: receiving a tuition debt policy request from anindividual via a remote device configured for display of fields forentry of covered individual information, including name, a schoolattended by the individual, a major, and a performance characteristicassociated with the individual at the school and for transmission ofdata entered in the displayed fields to the coverage processing computersystem, the request being received during an enrollment period prior toa graduation date of the covered individual; generating pricinginformation based at least in part on the request data; providing thepricing information and one or more tuition debt coverage optionscorresponding to the pricing information to the remote device fordisplay by the application program of the one or more tuition debtcoverage options and a user-selectable display element associated witheach of the one or more tuition debt coverage options for transmissionof a selection of one of the one or more tuition debt coverage options;receiving the selection of the selected one of the tuition debt coverageoptions from the remote device; storing, in a policy record data storagedevice, a policy record associated with the selected tuition debtcoverage option, the policy record including graduation and job searchrequirements to qualify for claim payments; and transmitting to theremote device an indication of coverage for the individual for thetuition debt coverage option, the coverage being active after thegraduation date and job search requirements have been validated; (b) aninformation server system, in communication with the coverage processingcomputer system, including at least one information processor configuredfor accessing and storing, during a time period after the enrollmentperiod and after a graduation date, job search data from data sourcesincluding job search sites and job agency databases relating to acovered individual, based on data received from the coverage processingcomputer system; and (c) a claims management server system including atleast one claims management processor configured for: determining aclaim payment amount for a claim under a tuition debt coverage policy,wherein the claim payment amount is determined based upon validation ofcovered individual information related to at least a graduation data andjob search data from the information server system, and data relating tocovered individuals connections on a business social media site; andissuing claim payment instructions for the determined claim paymentamount.
 2. The computer system of claim 1, wherein the at least onecoverage processor is further configured for: performing an auditfunction, after policy issue, by causing a display to be generated onthe remote device for a user to respond to one or more questions toconfirm one or more of: current enrollment school, current enrollmentstatus, current major and current grade point average; receiving fromthe remote device data responsive to the one or more questions;comparing the received data with stored data relating to the policy;responsive to, based on the comparison, determining that the data isunchanged or within one or more thresholds, determine that there is nopremium change and generate a message for display on the remote devicestating that there is no premium change; and responsive to, based on thecomparison, determining that one or more data items have changed,performing a premium recalculation, and notifying the covered individualof the recalculated premium.
 3. The computer system of claim 1, whereinthe claims management processor being configured for determining a claimpayment amount for a claim under a tuition debt coverage policydetermined based upon validation of covered individual informationfurther comprises: receiving information identifying the claim and thetuition debt coverage policy from a user device operated by a coveredindividual; retrieving, from a policy database, information associatedwith the tuition debt coverage policy; requesting covered individualinformation related to at least a graduation date and job search datafrom the information server system; and determining the claim paymentamount based on the validated covered individual information, thedetermining based at least in part on a number of the connections of thecovered individual data on the business social media site, weighting theconnections based on pertinence of field of the connections to a degreeof the covered individual.
 4. The computer system of claim 1, whereinthe at least one coverage processor is further configured for:interfacing with at least one of an employment agency computer system, ajob placement office computer system, a school placement office computersystem, and a state unemployment office computer system to obtain dataindicative of an employment status of the covered individual; andapplying unemployment validation rules stored by the coverage processorcomputer system to the data indicative of the employment status of thecovered individual; wherein the claims management processor isconfigured for determining the claim payment amount for the claim underthe tuition debt coverage policy further based upon the application ofthe unemployment validation rules to the data indicative of theemployment status of the covered individual.
 5. The computer system ofclaim 1, wherein the at least one coverage processor is furtherconfigured for: interfacing with at least one or more student loanprovider computer systems to obtain student loan data for the coveredindividual; and applying loan validation rules stored by the coverageprocessor computer system to the student loan data for the coveredindividual; wherein the claims management processor is configured fordetermining the claim payment amount for the claim under the tuitiondebt coverage policy further based upon the application of the loanvalidation rules to the student loan data for the covered individual. 6.The computer system of claim 1, wherein the at least one coverageprocessor is further configured for: interfacing with at least one ormore policy computer systems to obtain policy data for the coveredindividual relating to coverages other than the tuition debt coveragepolicy; and applying deductible rules stored by the coverage processorcomputer system to the policy data for the covered individual relatingto coverages other than the tuition debt coverage policy; wherein theclaims management processor is configured for determining the claimpayment amount for the claim under the tuition debt coverage policyfurther based upon the application of the deductible rules to the policydata for the covered individual relating to coverages other than thetuition debt coverage policy.
 7. The computer system of claim 1, whereinthe at least one coverage processor is further configured for: obtainingpremium payment information for the covered individual relating to thetuition debt coverage policy including electronic fund transfer data;and applying product rules stored by the coverage processor computersystem to the premium payment information for the covered individualrelating to the tuition debt coverage policy; wherein the claimsmanagement processor is configured for determining the claim paymentamount for the claim under the tuition debt coverage policy furtherbased upon application of the product rules to the premium paymentinformation for the covered individual relating to the tuition debtcoverage policy including the electronic fund transfer data.
 8. Thecomputer system of claim 1, wherein the at least one coverage processorbeing configured for issuing claim payment instructions for thedetermined claim payment amount comprises the at least one coverageprocessor being configured for issuing electronic fund transferinstructions for payment to a student loan provider computing system. 9.A computer system comprising: (a) a coverage processing computer systemincluding at least one coverage processor configured for: receiving atuition debt policy request from an individual via a remote deviceexecuting an application program configured for display of fields forentry of covered individual information, including name, a schoolattended by the individual, a major, and a performance characteristicassociated with the individual at the school and for transmission ofdata entered in the displayed fields to the coverage processing computersystem, the request being received during an enrollment period prior toa graduation date of the covered individual; generating pricinginformation based at least in part on the request data; providing thepricing information and one or more tuition debt coverage optionscorresponding to the pricing information to the remote device fordisplay by the application program of the one or more tuition debtcoverage options and a user-selectable display element associated witheach of the one or more tuition debt coverage options for transmissionof a selection of one of the one or more tuition debt coverage options;receiving the selection of the selected one of the tuition debt coverageoptions from the remote device; storing, in a policy record data storagedevice, a policy record associated with the selected tuition debtcoverage option, the policy record including graduation and job searchrequirements to qualify for claim payments; and transmitting to theremote device an indication of coverage for the individual for thetuition debt coverage option, the coverage being active after thegraduation date and job search requirements have been validated; and (b)a claims management server system including at least one claimsmanagement processor configured for: determining a claim payment amountfor a claim under a tuition debt coverage policy, wherein the claimpayment amount is determined based upon validation of covered individualinformation related to at least graduation data and job search datareceived from an information server system, and data relating to coveredindividuals connections on a business social media site; and issuingclaim payment instructions for the determined claim payment amount;wherein the at least one coverage processor is further configured for:interfacing with at least one of an employment agency computer system, ajob placement office computer system, a school placement office computersystem, and a state unemployment office computer system to obtain dataindicative of an employment status of the covered individual; andapplying unemployment validation rules stored by the coverage processorcomputer system to the data indicative of the employment status of thecovered individual; wherein the claims management processor isconfigured for determining the claim payment amount for the claim underthe tuition debt coverage policy further based upon the application ofthe unemployment validation rules to the data indicative of theemployment status of the covered individual.
 10. The computer system ofclaim 9, further comprising: the information server system, wherein theinformation server system is in communication with the coverageprocessing computer system, the information server system including atleast one information processor configured for accessing and storing,during a time period after the enrollment period and after a graduationdate, the job search data from data sources including job search sitesand job agency databases relating to a covered individual, based on datareceived from the coverage processing computer system.
 11. The computersystem of claim 9, wherein the at least one coverage processor isfurther configured for: performing an audit function, after policyissue, by causing the remote device to generate a display for a user torespond to one or more questions to confirm one or more of: currentenrollment school, current enrollment status, current major and currentgrade point average; receiving from the remote device data responsive tothe one or more questions; comparing the received data with stored datarelating to the policy; responsive to, based on the comparison,determining that the data is unchanged or within one or more thresholds,determine that there is no premium change and generate a message fordisplay on the remote device stating that there is no premium change;and responsive to, based on the comparison, determining that one or moredata items have changed, performing a premium recalculation, andnotifying the covered individual of the recalculated premium.
 12. Thecomputer system of claim 9, wherein the claims management processorbeing configured for determining a claim payment amount for a claimunder a tuition debt coverage policy determined based upon validation ofcovered individual information further comprises: receiving informationidentifying the claim and the tuition debt coverage policy from a userdevice operated by a covered individual; retrieving, from a policydatabase, information associated with the tuition debt coverage policy;requesting covered individual information related to at least agraduation date and job search data from the information server system;and determining the claim payment amount based on the validated coveredindividual information, the determining based at least in part on anumber of the connections of the covered individual data on the businesssocial media site, weighting the connections based on pertinence offield of the connections to a degree of the covered individual.
 13. Thecomputer system of claim 9, wherein the at least one coverage processoris further configured for: interfacing with at least one or more studentloan provider computer systems to obtain student loan data for thecovered individual; and applying loan validation rules stored by thecoverage processor computer system to the student loan data for thecovered individual; wherein the claims management processor isconfigured for determining the claim payment amount for the claim underthe tuition debt coverage policy further based upon the application ofthe loan validation rules to the student loan data for the coveredindividual.
 14. The computer system of claim 9, wherein the at least onecoverage processor is further configured for: interfacing with at leastone or more policy computer systems to obtain policy data for thecovered individual relating to coverages other than the tuition debtcoverage policy; and applying deductible rules stored by the coverageprocessor computer system to the policy data for the covered individualrelating to coverages other than the tuition debt coverage policy;wherein the claims management processor is configured for determiningthe claim payment amount for the claim under the tuition debt coveragepolicy further based upon the application of the deductible rules to thepolicy data for the covered individual relating to coverages other thanthe tuition debt coverage policy.
 15. The computer system of claim 9,wherein the at least one coverage processor is further configured for:obtaining premium payment information for the covered individualrelating to the tuition debt coverage policy including electronic fundtransfer data; and applying product rules stored by the coverageprocessor computer system to the premium payment information for thecovered individual relating to the tuition debt coverage policy; whereinthe claims management processor is configured for determining the claimpayment amount for the claim under the tuition debt coverage policyfurther based upon application of the product rules to the premiumpayment information for the covered individual relating to the tuitiondebt coverage policy including the electronic fund transfer data. 16.The computer system of claim 9, wherein the at least one coverageprocessor being configured for issuing claim payment instructions forthe determined claim payment amount comprises the at least one coverageprocessor being configured for issuing electronic fund transferinstructions for payment to a student loan provider computing system.